perm filename LETTER.PS[P,JRA] blob sn#153676 filedate 1975-04-03 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\\M1BASL30\M2BASB30\M3NGR25\M4NGR20\F2\CSTANFORD UNIVERSITY
C00010 ENDMK
C⊗;
\\M1BASL30;\M2BASB30;\M3NGR25;\M4NGR20;\F2\CSTANFORD UNIVERSITY
\F3\CSTANFORD, CALIFORNIA 94305
\F4COMPUTER SCIENCE DEPARTMENT\←L\-R\/'7;\+R\→.\→S   Telephone:
\←S\→.415-497-4971
\F1\CApril 3, 1975



Dr. Patrick Suppes, Director
IMSSS, Ventrua Hall




Dear Dr. Suppes:

\JAs you know, I have been working with David Luckham for many years.
In the last few years our research interests have become more and more divergent
and recently we have decided to go our separate ways. I would like to
describe some of my ideas to you and if you find them interesting then
perhaps we could talk further.

Basically I have become increasingly discontented with the lack of progress
in the field of education of programmers. The poor quality of education
has direct bearing on the "software problem", and I do not believe that
the current research into automatic programming, verification, or 
knowledge-based systems is going to do much to alleviate the problems.

While teaching at UCLA a few years ago, I began writing a book on 
LISP as a language for describing data structure algorithms. The 
material has been embellished, revised and re-thought in the intervening
years and will be published by McGraw-Hill as soon as I finish it.
The  book is  much more than a book on LISP, but is a philosophy of
education in Computer Science. 
Judging from my teaching experience --UCLA, UCSC, and  current
missionary work at San Jose State-- and judging from the reviews of the
manuscript, I feel that my approach has a good chance of revising 
the current tend of simply producing sophisticated coders.
This may seem a bit presumptuous, but
I have very strong feelings about Computer Science education and
Curriculum '68 in particular. I have had a letter accepted (subject to 
revisions) for
publication in the CACM Forum attacking the structure of undergraduate
education.

This leads me finally to some of my research interests. In particular,
the style of my book --influenced strongly by Dijkstra-- lends itself
well to the design of a complimentary programming lab which will
support systematic construction of correct programs. 
It seems to me that several ingredients are missing in the discussions
of "structured programming". Certainly one missing quantity is precision.
My book  shows the necessity of considering "abstraction" in any such
discussion. What is more important, is that  people ignore the "-ing"
of "structured programming". It is the process of systematic development
of the program --moving from abstract to concrete-- which is important. 
The "monologue" which an instructor uses in describing the development
of an abstract algorithm, can be used as the rudiments of a command
language to guide the construction of the program.
This is one of the areas which a programming lab can support and reinforce.
The outgrowth of such a combination --pedagogy supported by a programming
lab-- should demonstrate the benefits of structured programming. 
This demonstration has been lacking in discussion of programming
style and methodology. If we are to have serious impact on current
programming practice we must demonstrate that programmers trained
in our style, write more reliable, more readable programs.

Thus one level of the investigation should be the construction of a 
realistic programming environment, supporting  "structured programming".
The working environment which I envision is highly interactive, using
display terminals, not teletype-like devices. I have several novel ideas
on  how such a system should be designed and how users can benefit
from its use.  The system will enhance the user's general feeling
of manageability during the construction of his program. This
manageability  translates into an informal feeling of correctness.

At a more theoretical level
we must attack the formal problems of correctness of programs. Current
work in verification tends to concentrate on attempts to validate
already existing programs. I find this unrealistic and objectionable
for several reasons. What I propose is rather to attack the questions
of validation while the program is being constructed. It turns out the
programming philosophy I'm espousing couples nicely with some of the
recent work in verification. One result is to bring validation tools
down into the actual construction phase. Again these formal rules
translate into on-line commands for an interactive programming system.

So to summarize, I am proposing to exploit a specific pedagogical
philosophy, extending it into a realistic programming lab. The 
lab should be an exceptionally vaild CAI tool for teaching a real
understanding of algorithms. It should also be a valuable tool for the
practicioner (I would use it), allowing him to more easily construct reliable complex software.

If you would like to talk with me, please call.\.
\←L\→S\←R\-L\/'2;\+L\→L

Yours sincerely,



John R. Allen
Research Associate
Computer Science Dept
Artificial Intelligence Lab

\←S\→L